1. Field of the Invention
The present invention relates to a session-based service of an IP Multimedia Subsystem (IMS), and particularly, to a user equipment (UE), method and system for controlling a simultaneous session for services such as a Push-to-Talk over Cellular (PoC) service.
2. Discussion of the Related Art
In general, in an RFC 3261 document of an Internet Engineering Task Force (IETF), operation methods of Session Initiation Protocol (SIP) servers such as a PoC server may be divided into a SIP proxy method and a Back-to-Back User Agent (B2BUA) method.
FIGS. 1 and 2 are flow diagrams for explaining respectively the B2BUA method and the SIP proxy method according to the related art.
As illustrated in FIG. 1, in the B2BUA mode of operation, Real Time Protocol (RTP) data, Real Time Control Protocol (RTCP) data and Talk Burst Control Protocol (TBCP) data as well as SIP messages, which are transmitted and received between a PoC client and a PoC server B (server performing a controlling function), must always pass through a PoC server A (server performing a participating function). Similarly, as illustrated in FIG. 2, in the SIP proxy mode of operation, SIP messages transmitted and received between the PoC client and the PoC server B always pass through the PoC server A. However, in the SIP proxy mode, RTP data, RTCP data and TBCP data do not pass through the PoC server A, but are directly transmitted and received between the PoC client and the PoC server B.
As such, the SIP proxy mode and the B2BUA mode are distinguishable from each other depending on whether the RTP, RTCP and TBCP data pass through the PoC server A. That is, as illustrated in FIG. 1, when the PoC server A operates in a B2BUA mode, RTP, RTCP and TBCP data which are transmitted and received between the PoC client and the PoC server B always pass through the PoC server A. However, as illustrated in FIG. 2, when the PoC server A operates in a SIP proxy mode, RTP, RTCP and TBCP data which are transmitted and received between the PoC client and the PoC server B do not pass through the PoC server A. The PoC server A operating in the SIP proxy mode according to the related art cannot and does not receive the RTP, RTCP and TBCP data from the PoC client or PoC server B, and accordingly can not control such data. However, there are situations when such control is needed.
As known, a PoC server has both a controlling PoC function and a participating PoC function. The controlling PoC function of the PoC server provides a centralized PoC session handling including RTP media distribution, Talk Burst control, policy enhancement for participating in a group session, participant information control, and the like. The participating PoC function of the PoC server provides policy enhancement for incoming PoC sessions, and a PoC session processing for relaying a Talk Burst control message between the PoC client and the PoC server which performs the controlling PoC function. The participating PoC function can relay an RTP media between the PoC client and the PoC server which performs the controlling PoC function.
The participating PoC function of a PoC server (e.g., PoC server A) can support (capable of providing) a ‘simultaneous PoC session’ for the PoC client. In the present disclosure, a ‘simultaneous PoC session’ is a session during which the PoC server performs a PoC session priority function or a PoC locking function. The PoC session priority function by the PoC server gives priority to a specific PoC session for the PoC client that has initiated or received invitations to a plurality of PoC sessions. The PoC locking function by the PoC server allows transmission of media data related to only a specific PoC session to the PoC client while holding off transmission of media data associated with other sessions. In this way, the simultaneous PoC session may be said to involve filtering certain data (e.g., RTP data sets) to provide only one RTP data set, e.g., corresponding to the locked session or primary session. Some PoC servers and PoC clients may support the simultaneous PoC session while some PoC servers and PoC clients may not support the simultaneous PoC session.
As an example, assume there are a PoC client and a PoC server that support and carry out a simultaneous PoC session. According to the PoC session priority function, the PoC client sets only one PoC session as Primary one, and other PoC sessions as Secondary ones. Preferably, a value of such PoC session priority is transferred from the PoC client to the PoC server which performs the participating PoC function (e.g., the PoC server A) using an INVITE, RE-INVITE or UPDATE message.
Upon setting the PoC session priority value, the PoC server performing the participating function (PoC server A) transfers data to the PoC client based upon the set PoC session priority value. Namely, once a PoC session is set as Primary, when media data from the primary PoC session is received while the PoC server receives media data from the secondary PoC sessions, the PoC client can immediately receive the media data of the primary PoC session over the media data of the secondary PoC sessions under control of the PoC server A. That is, according to the session priority set by the PoC client, the PoC server A can selectively transmit (transmit or not transmit) media data associated with each PoC session to the PoC client in certain priority order.
On the other hand, according to the PoC locking function, the PoC client sets ‘locking’ (to be locked) to one PoC session, and thus may receive media data related to only the locked PoC session while it does not receive media data related to other PoC sessions from the PoC server A (server performing the participating function). In this way the locking function blocks out media data of certain PoC sessions. Preferably, the PoC session locking value is transferred from the PoC client to the PoC server A through an INVITE, RE-INVITE or UPDATE message, and is set in the PoC server A. Upon setting the PoC session locking value, the PoC server A determines whether or not to transfer media data to the PoC client on the basis of the set PoC session locking value, and selectively transfers (transfers or not transfers) the media data to the PoC client according to the determination result.
Therefore, in order to perform a simultaneous PoC session (e.g., a PoC session priority function, a PoC locking function, etc.) for a PoC service, as illustrated in FIG. 1, media data including RTP data, RTCP data, TBCP data, etc. need to pass through the PoC server A (performing the participating function) when communicated between the PoC client and the PoC server B (performing the controlling function) since the PoC server A must control the data flow according to the PoC locking function or PoC session priority function. For instance, the PoC server A performing the participating PoC function needs to receive the RTP data (e.g., media data such as voice, video, or the like), which has been transmitted toward the PoC client from the PoC server B performing the controlling PoC function, in the course of transmitting the corresponding data, so that the PoC server A can determine whether to transfer the received RTP data to the PoC client so as to implement the PoC locking function or PoC session priority function.
In other words, to carry out a simultaneous PoC session, the PoC server A which performs the participating PoC function should always operate in the B2BUA mode (and not in the SIP proxy mode), so as to ensure that every media data is passed through the PoC server which performs the participating PoC function. However, in a simultaneous PoC session according to the related art, the PoC server can operate either in the B2BUA mode or the SIP proxy mode and does not know whether the PoC client supports the simultaneous PoC session. When the PoC server which performs the participating PoC function does not operate in the B2BUA mode but operates in the SIP proxy mode when a simultaneous PoC session service is provided, problems may occur as follows.
When a simultaneous PoC session service is provided, if one PoC client is involved in several PoC sessions, the PoC client sets the PoC locking function to one particular PoC session, and thus can request the PoC server performing the participating PoC function to transmit media data associated with only the locked PoC session through the locked PoC session. However, in this case, if the PoC server is operating in a SIP proxy mode, then the media data sent by the PoC server performing the controlling PoC function are sent directly to the PoC client without being passed through the PoC server performing the participating PoC function. Accordingly, the PoC server performing the participating PoC function can not implement the PoC locking function as requested by the PoC client. Similar problems exist when implementing a PoC session priority function of the simultaneous PoC session.
Also, when both the PoC client and the PoC server support the simultaneous PoC session, the PoC server performing the participating PoC function may exist on a media path (e.g., between the PoC client and the PoC server performing the controlling PoC function), and thus performs a relay function of receiving the media data and then transmitting the received media data. However, according to the related art, the PoC server performing the participating PoC function can not recognize whether or not the PoC client supports the simultaneous PoC session. Accordingly, the PoC server performing the participating PoC function can not know the number of maximum simultaneous sessions supported by each PoC client, and thereby cannot properly deal with PoC session settings requested by the PoC client.
Furthermore, such problems can also exist in other types of all IP (internet protocol)-based services (e.g., SIP-based message services) when controlling a simultaneous session (or the like) operation.